Field of the Invention
The present invention generally relates to data storage systems. More particularly, the present invention relates to a method and apparatus for providing access to data in unsupported file systems and storage containers.
Description of the Related Art
An operating system (OS) normally includes one or more file systems. The file system provides a structure for storing and organizing computer files and the data they contain to make the data easy to find and access them. A file system is a set of abstract data types that are implemented for the storage, hierarchical organization, manipulation, navigation, access and retrieval of data.
Owing to the fact that all operating systems include support for variety of file systems, operating systems interact with the supported file systems. Specifically, operating systems have drivers or special functions for interaction with the supported file systems. For example, Microsoft Windows NT, 2000 and XP have a default file system Application Programming Interface (API) known as a file system driver for the NTFS, FAT and FAT32 file systems. File system drivers enable the operating system to interface with the file system. The OS usually provides abstractions for accessing different file systems transparently to users, and in this sense it is analogous to device driver APIs that provide abstracted access to hardware.
In certain applications, virtual machines help run file systems on a guest OS that are unsupported by the primary OS. However, certain file systems simply cannot be accessed by popular/normal operating systems, such as Windows or Mac OS. For example, esoteric (or new) file systems, such as FLICKRFS, GMAILFS, S3FS, VERSIONING FILE SYSTEMS and VERITAS File Systems known as VxFS, can only be made accessible to an OS through the use of OS-specific file system development tools or software development kits (SDKs). Besides, networks comprising numerous servers, clients and storage devices have difficulty accessing (reading/writing file data) the data mounted by the unsupported file systems. In particular, these networks cannot provide file-level access to the data for the enterprise through a seamless network shared file system because of the unsupported file systems. These are some of the major problems faced.
Typically, storage containers are devices that store data in arrays of optical or magnetic disk drives and may be online at remote locations with respect to a user's computer. In some applications, esoteric (e.g., unsupported or new) storage containers suffer from similar problems as the unsupported file systems. Specifically, popular/normal operating systems do not understand the format or arrangement of the data blocks in the unsupported storage containers and cannot access the data (read/write blocks). To mitigate such problems, operating systems need a dedicated device driver written for the OS-specific driver model. This in turn implies that there has to be separate sets of codes for different versions or distributions of each OS. For example, one set of code has to be written and maintained for WINDOWS, another one for MAC OS, a third for LINUX and so on.
However, even with good cross-platform coding practices using portable languages (or platform-independent languages) it is still necessary to write OS-specific code and conduct quality analysis (QA) on every version for every OS. This is owing to the fact that there is a possibility of differences in the specific compilers and absence of runtime library routines on all platforms or semantics and inter-component interactions specific to each platform. For instance, even a language such as JAVA supposedly designed to be portable has not achieved that objective—the old adage “write once, debug everywhere” still applies.
Accordingly, there is a need in the art for method and apparatus for providing access to data in unsupported file systems and storage containers.